[% setvar title The Perl 6 Summary for the week ending 20030511 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030511'></a><h1>The Perl 6 Summary for the week ending 20030511</h1>
<p>PEPPERPOT 1: Ooh look! It's another Perl 6 summary!</p>
<p>PEPPERPOT 2: Well I never did! What's in it this week?</p>
<p>PP 1: Ooh, I don't know. Shall we have a look?</p>
<p>PP 2: Ooh yes.</p>
<p>Following a convoluted animation sequence involving surreality,
fig leaves, classical statuary, and a cardboard cutout of an orange
Leon Brocard, the camera pulls back to reveal a large bearded man, sat
in a leather chair with a huge Apple PowerBook on his lap. PIERS looks
from the screen to the camera and says</p>
<p>PIERS: I never wanted to be a summary writer. I wanted to be a
lumberjack, leaping from tree to tree as they float down the mighty
rivers of Briti... Ah... *ahem*.</p>
<p>PIERS comes to a stammering stop as he realises that quoting Python is
<i>so</i> 20 years ago and that this year all the cool London.pm kids are
quoting <i>Buffy the Vampire Slayer</i> instead.</p>
<p>Anyhoo.</p>
<p>As you may have gathered from the above introduction, it's been fairly
quiet this week. However, design, development and discussion
continues. As usual we'll start with perl6-internals.</p>
<a name='Long option Processing'></a><h2>Long option Processing</h2>
<p>Towards the end of April, Luke Palmer had posted a patch implementing
a long option processing subsystem for Parrot. After wondering if
<code>getopt_long</code> was a standard function (it isn't), Steve Fink applied
the patch.</p>
<p><a href='http://groups.google.com/groups?threadm=ygcd6j7f063.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Excessive memory usage?'></a><h2>Excessive memory usage?</h2>
<p>Leo T&ouml;tsch responded to Peter Gibbs' question of the week before
about Parrot's apparently excessive memory use for a simple
program. Leo and Peter batted the issue back and forth a few times
in the process of tracking down the source of the problem. I think
they got to the root of the problem, but I'm not sure if they've
worked out a fix just yet.</p>
<p><a href='http://groups.google.com/groups?threadm=a4jtbvodfn04q0cj8qpprfr3m5pbp681sa@4ax.com' target='_blank'>groups.google.com</a></p>
<a name='NCI and handling of generic buffers of stuff'></a><h2>NCI and handling of generic buffers of stuff</h2>
<p>Last week Clinton A. Pierce had wondered about allocating blocks of
'generic' memory within Parrot for use as targets for native functions
(in his case for calling Win32 functions). Piers Cawley wondered if it
wouldn't be possible to implement a scratch buffer PMC to manage such
blocks of memory. Dan pointed out that this was exactly what the
'unmanagedstruct' PMC type was intended for, but Clint wasn't sure
that this did quite what he wanted and asked for more advice.</p>
<p>Later in the week Clint announced that he'd got UnManagedStruct PMCs
doing some useful work, including allocating arbitrarily sized buffers
from parrot assembly. People were impressed (In fact, Dan went so far
as to call Clint his hero in his 'Squawks of the Parrot'
weblog). However, Leo T&ouml;tsch pointed out that a good deal of the
work that Clint had done on UnManagedStruct probably belonged on
ManagedStruct instead. Apparently Clint (and Dan) hadn't noticed that
ManagedStruct existed. Hopefully now he's had it pointed out to him,
things will become a little more logical.</p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030502162515.01faee68@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030505154331.02608008@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.sidhe.org/~dan/blog/archives/000186.html' target='_blank'>www.sidhe.org</a></p>
<a name='Calling convention changes'></a><h2>Calling convention changes</h2>
<p>After Dan's last set of changes to the Parrot calling conventions,
Brent Dax wondered why we still had a user stack now that it was no
longer being used for argument passing. Klaas-Jan Stol reckoned it was
still useful and it would make targetting Parrot easier. Luke Palmer
wondered if the user stack wouldn't make it harder to implement an
exception system.</p>
<p>Interestingly, Dan seems to be toying with having Parrot use
Continuation Passing Style function calls at some point in the
future. Who knows, maybe the next final calling conventions will
mandate CPS (I confess, I rather like the idea myself...)</p>
<p><a href='http://groups.google.com/groups?threadm=001b01c3129d$16fbec00$6501a8c0@deepblue' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.sidhe.org/~dan/blog/archives/000187.html' target='_blank'>www.sidhe.org</a></p>
<a name='Building Parrot on windows'></a><h2>Building Parrot on windows</h2>
<p>Getting Parrot working well in a Win32 environment seems to have been
a Parrot theme over the last few weeks. This week Cal Henderson popped
up with some problems getting things to link. The problem was tracked
down quite quickly, and Cal ended up offering to do regular windows
builds for the tinderbox system, though it looks like that's not yet
as easy as it could be. Apparently the standard Win32 make targets
don't quite build enough. I'm sure someone's working on fixing this;
getting Win32 into the tinderbox will be really handy.</p>
<p><a href='http://groups.google.com/groups?threadm=20030505000930.A2FB736C1B4@neuron.neuron1.com' target='_blank'>groups.google.com</a></p>
<a name='IMCC vs. Parrot assembler'></a><h2>IMCC vs. Parrot assembler</h2>
<p>Zellyn Hunter wondered about how to choose between IMCC and the native
parrot assembler. (Zellyn also presented me with a dilemma about which
personal pronoun to use, which I solved by going and looking at his website.
Unless 'Leah' turns out to be a chap's name I think I'm safe). He also
asked about the state of the documentation within CVS, and wondered
which documents were still valid and which (if any) had been caught
out by the march of development, suggesting a small meta document with
information on the validity of the various docs (which begs the
question of how one knows that the metadoc is up to date.)</p>
<p>The answer to the first question was &quot;Well, it depends&quot;, with the
rider that, unless you enjoyed doing your own register allocation,
IMCC looked like the saner choice. Jerome Quelin pointed out that the
Ook! compiler targets PASM, which seems to be in agreement with the
whole sane/unsane thing.</p>
<p><a href='http://groups.google.com/groups?threadm=200305042151.08781.zellyn@zellyn.com' target='_blank'>groups.google.com</a></p>
<a name='More on stack walking'></a><h2>More on stack walking</h2>
<p>David Robins read Dan's blog entry about stack walking and had a few
questions about the details. He wanted to know what was done about
false positives (ie, how do you <i>know</i> that something that looks like
a pointer <i>is</i> a pointer), and what was done about object
destruction. Dan replied that, in one of the Parrot GC system's few
conservative choices, Parrot GC took the view that if something in the
system stack looks like a pointer then it's safest to assume that it
is a pointer and proceed on that basis. He also noted that, if a
language required a specific order of object destruction then it was
down to the language to handle that.</p>
<p>The usual spectre of timely closure of IO handles was raised again --
Perl 5 guarantees that objects get destroyed (and therefore handles
get closed) as soon as an object goes out of scope. This is somewhat
harder to guarantee in a system that doesn't use reference counting
for garbage collection. Graham Barr commented that &quot;Anyone who depends
on GC for the closing of file handles asks for all they get.&quot;, which
is certainly one way of approaching the issue, but it does rather fly
in the face of the Perl 5 Way.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.44.0305051420580.29147-100000@davidrobins.net' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.sidhe.org/~dan/blog/archives/000174.html' target='_blank'>www.sidhe.org</a> -- Dan explains
stack walking</p>
<a name='PIO work'></a><h2>PIO work</h2>
<p>J&uuml;rgen B&ouml;mmels continued his sterling work on the Parrot
IO system (PIO), fixing up the problems with buffering and double
frees etc that were mentioned last week.</p>
<a name='sysinfo op'></a><h2><code>sysinfo</code> op</h2>
<p>Dan added a <code>sysinfo</code> op which allows a running program to at least
get some information about the machine it's running on. Things are
apparently somewhat spotty for various architectures that Dan didn't
have immediate access to, but there's a framework in place now and
patches are welcome.</p>
<p><a href='http://groups.google.com/groups?threadm=a05210600bae4339e14ef@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Meanwhile in perl6-language'></a><h1>Meanwhile in perl6-language</h1>
<p>The language list was again busier than the internals list this week,
but only just. Maybe we're all waiting with bated breath for the next
exegesis. Or maybe everyone's exhausted. It can't last though.</p>
<a name='bool Type'></a><h2><code>bool</code> Type</h2>
<p>Discussion of the hypothetical/non-existent <code>bool</code> type continued. I
tried really hard to care.</p>
<a name='Coroutine calling convention'></a><h2>Coroutine calling convention</h2>
<p>As Luke Palmer continued to argue that Coroutines were a
useless/dangerous bit of syntactic sugar and we'd be better using
explicit iterator objects. Meanwhile, others discussed the various
options for calling semantics in the case where Coroutines continued
to look like coroutines instead of iterators. Damian Conway proposed
another form of Coroutine calling convention. Damian proposed that
<code>yield</code> return the 'new' arguments with which you 'resumed' the
coroutine. This gives the programmer the option to handle different
arguments however she likes. Piers Cawley liked the idea and posted a
few snippets of code for implementing these semantics using
continuations. He also suggested that it might be handy to be able to
declare 'Blocklike' subroutines that were 'return transparent'. I
think the continuations scared people off because there has been no
comment, even on the Blocklike subs idea.</p>
<p><a href='http://groups.google.com/groups?threadm=ygcvfwtici9.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3EB65E4A.1000504@conway.org' target='_blank'>groups.google.com</a> -- Damian's proposal</p>
<a name='Include macro'></a><h2>Include macro</h2>
<p>Uri Guttman, may his name be forever mispronounced, responded to last
week's summary (instead of the original thread, <i>bad</i> Uri!) by
pointing out that the simple minded include macro referred to in that
summary was inefficient and proposed an optimization. This turned into
a discussion of whether file reads should be 'slurpy' by default
(Michael Lazzaro thought they should be, almost everyone else disagreed
with him).</p>
<p>Then Damian popped up with his proposed Grand Unification
of HERE docs, POD, and general file slurping, which looks very cool,
but unfortunately, the unary <code>&lt;&lt;</code> operator that Damian proposes
to hang all this off seems to clash with Larry's proposed use of <code>
&lt;&lt;list of words&gt;&gt;</code> as a replacement for
<code>qw/.../</code>. The idea was well received, and people started casting
around for a sensible operator and adding other neat ideas to go with
it. Damian won the 'evil, evil, evil' prize when, after <code>&lt;&lt;&lt;</code> had
been proposed as the file slurp operator, he came up with the idea of
vectorizing it, which would lead to such delights as</p>
<pre>    my($stdout, $stderr) = &gt;&gt;&lt;&lt;&lt;&lt;&lt; open 'grep foo * |';</pre>
<p>Or, for the avoidance of headaches:</p>
<pre>    my($stdout, $stderr) = &gt;&gt; &lt;&lt;&lt; &lt;&lt; open 'grep foo * |';</pre>
<p>(I hate to think how one would write that in a POD C&lt;...&gt;
escape).</p>
<p>This then turned into a discussion of whether <code>&lt;&lt;...&gt;&gt;</code> made
sense as a replacement for <code>qw&lt;...&gt;</code>, especially given the
perceived utility of Damian's proposal.</p>
<p>Towards the end of the thread, Michael Lazzaro withdrew his contention
that slurpy reads should be the default.</p>
<p><a href='http://groups.google.com/groups?threadm=x765opwbzh.fsf@mail.sysarch.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3EB89C0F.4050607@conway.org' target='_blank'>groups.google.com</a> -- Conway's Unified Here Theory</p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>The camera pulls back from observing a computer screen on which the
words &quot;The camera pulls back from...&quot; are being typed and swings
around to focus on the typist who looks up from the screen and
addresses the camera.</p>
<p>PIERS: And so, by some extraordinary coincidence, fate, it seemed,
had decided that you, my readers, should keep your appointment with
the end of this summary. But what of the new technologies that had
been spoken of?</p>
<p>AUDIENCE: Where *BLEEP*?</p>
<p>PIERS: In an empty house?</p>
<p>AUDIENCE: When *BLEEP*?</p>
<p>PIERS: In the middle of the night?</p>
<p>AUDIENCE: Best time!</p>
<p>PIERS: What diabolical plan had been shaped by Damian and Larry's
crazed imaginations? What indeed? From what had gone before it was
clear that this was going to be...</p>
<p>AUDIENCE: a picnic?</p>
<p>PIERS: no picnic.</p>
<p>AUDIENCE: Awwwww!</p>
<p>The lights dim, the screen fades to white and the following words
scroll up the screens of browsers the world over:</p>
<p>If you've appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or a better framing device than terrible pastiches of Monty Python and the Rocky Horror Show to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>. People suggesting an MST3K version of this summary can jolly well do it themselves.'></a>Send feedback, flames, money, photographic and writing commissions, or
a better framing device than terrible pastiches of Monty Python and
the Rocky Horror Show to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>. People
suggesting an MST3K version of this summary can jolly well do it
themselves.</li>
</ul>
</div>
